Application No. 10/039,932 

Reply to the Advisory Action of March 22, 2007 and the Official Action of January 30, 2006 
REMARKS/ARGUMENTS 

Favorable reconsideration of this application, as presently amended and in light of the 
following discussion, is respectfully requested. 

Claims 1-4, 6-10, 12-17, 19-23, 25 and 27-49 are pending, with Claims 1, 6-10, 15, 19 
and 27 amended, and Claims 5 and 1 8 canceled by the present amendment. 

In the Official Action of June 30, 2006, Claims 1-10, 12-23, 25 and 27-49 were 
rejected under 35 U.S.C. §103(a) as being unpatentable over Kawai (U.S. Patent 6,137,485) 
in view of Comstock (sic U.S. Patent 5,692,073). 

Applicants acknowledge with appreciation the telephone interview between the 
Examiner and Applicants' representative on October 24, 2006 in which the Examiner 
acknowledged that the Official Action contains a typographical error and that Comstock 
should be identified as U.S. Patent 6,704,769 not U.S. Patent 5,692,073. 

Claims 1 and 15 are amended to recite the features of cancelled Claims 5 and 18, 
respectively. Claim 27 is also amended to recite the features of cancelled Claim 18. Claims 
6-10 and 19 are amended for antecedent basis. No new matter is added. 

Claim 1 is directed to a system for managing video teleconferencing devices 
configured to exchange audio/video data. The system includes a management adapter (Fig. 1 , 
item 14) accessible to a user interface (Fig. 1, item 12), the management adapter having a list 
that identifies the video teleconferencing devices configured to exchange audio/video data, 
and a device access layer (Fig. 1, item 26) interfaced with the management adapter and the 
video teleconferencing devices. The device access layer represents the video 
teleconferencing devices as objects to support management of the video teleconferencing 
devices through the management adapter during set-up or conduct of an active video 
teleconference (Specification, page 13, lines 15-17). The video teleconferencing devices 
have plural video teleconferencing types, the device access layer representing each type of 
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video teleconferencing device as an object class (Specification, page 13, lines 17-24; see also 
page 13, line 29 - page 14, line 10). Claim 15 is directed to a method substantially 
corresponding to the apparatus recited in Claim 1 . Claim 27 is directed to an alternative 
embodiment of the method of Claim 15. 

Dependent Claim 2 recites that the device access layer represents the video 
teleconferencing devices as Management Beans. A Management Bean is a JAVA software 
construct (Specification, page 14, line 1 1 - page 15, line 11; see also item 60 of Fig. 3B). 
Claims 3, 4, 12, 13, 14, 16, 20, 23, 32 and 44 also recite Management Beans. 

Claim 20 is directed to a method for interfacing an SNMP management application 
with plural video teleconferencing devices having disparate native interface protocols. The 
method includes representing each video teleconferencing device as a Management Bean 
stored on a server (Specification, page 15, lines 27-30; see also Figs. 2-3), providing an 
SNMP management instruction for a video teleconferencing device to an SNMP adapter 
(Specification, page 17, lines 1-17; see also Figs. 2-3), communicating the SNMP 
management instruction using the SNMP adapter as a management bean client in 
communication with the server (Specification, page 17, lines 1-17; see also Figs. 2-3), and 
communicating the SNMP management instruction from the server through the management 
bean representing the video teleconferencing device to the video teleconferencing device in a 
native protocol of the device (Specification, page 17, lines 1-17; see also Figs. 2-3), and 
sending audio/video data from one of said plural video teleconferencing devices to another of 
said plural video teleconferencing devices (Fig. 3). Claim 25 is directed to a system 
substantially corresponding to the method of Claim 20, albeit without recitation of 
Management Beans. 

Claim 36 is directed to a system for managing a video network having plural video 
teleconferencing devices. The system includes plural objects, each object having attributes to 
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represent a video teleconferencing network device, one or more lists of the attributes, one or 
more MIB having variables of the video teleconferencing network device (Specification, page 
20, lines 9-28; Fig. 4 items 68, 70, 72, 76 and 78), and a MIB summation engine (Fig. 4, item 
66) operational to select one or more attributes and one or more variables to dynamically 
create a MIB (Fig. 4, item 80; specification page 20, line 19 - page 22, line 22) for the video 
teleconferencing device during set-up or conduct of an active video teleconference. Claim 45 
is directed to a method substantially corresponding to the system of Claim 36. 

The first issue is whether Kawai or Comstock disclose or suggest a device access 
layer representing each type of video teleconferencing device as an object class as recited in 
Claims 1, 15 and 27. 

The second issue is whether Kawai or Comstock disclose a management bean as 
recited in Claims 2, 3, 4, 12, 13, 14, 16, 20, 23, 32 and 44. 

The third issue is whether Kawai or Comstock disclose or suggest an SNMP 
management instruction for a video teleconferencing device as recited in Claims 20 and 25. 

The fourth issue is whether Kawai or Comstock disclose an MIB having variables of a 
video teleconferencing device or a MIB summation engine operational to select one or more 
attributes and one or more variables to dynamically create a MIB as recited in independent 
Claims 36 and 45. 

A. Kawai and Comstock each fail to disclose or suggest a device access layer 
representing each type of video teleconferencing device as an object class as 
recited in Claims 1,15 and 27. 

Kawai discloses a variety of methods for remotely controlling cameras in a video 

teleconference, and providing an indication on a variety of video conference terminals for 

which terminal is controlling which camera. In Figure 3 of Kawai , reference numeral 60 

denotes an observer list field for displaying a list of observers who are observing the image 

picked up by the video camera 30 and transmitted onto the network 12. The list field 60 
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displays the login name of the communication terminal of each observer. If there are a 
plurality of observers, the list field 60 displays a list of the login names of all of the 
observers. Reference numeral 62 denotes an operator field for displaying the name of an 
operator who is remote controlling the camera 30 at present. 1 Kawai also discloses an access 
management process 78 that manages the remote control operations and image distribution 
operations of cameras 30 of all the video communications terminals 10-1, 10-2, 10-3 and 10- 
4 connected to the network 12. As acknowledged in the Official Action, Kawai does not 
disclose or suggest the use of objects. To cure this deficiency, the Official Action cites 
Comstock . 

Comstock discloses a system apparatus and method for managing media in a 
multimedia conferencing system according to media roles. Examples of media roles include 
"people" or "content." Page 2 of the Official Action asserts that Figure 1 of Comstock 
teaches the representation of devices as objects. Applicants traverse and note that Figure 1 is 
merely a diagram of a variety of devices connected to a network. The Official Action also 
cites column 3, lines 20-55 of Comstock . However, this citation also fails to disclose an 
object or any other type of control device or schema. This section of Comstock merely 
describes what types of devices may be connected together via a network, but does not 
disclose or suggest classifying devices as objects in software, let alone by object type. 

While not cited in the Official Action or Advisory Action, Applicants contend that the 
only possible portion of Comstock that might be remotely relevant to Applicants' claimed 
invention is the portion that describes call manager 135 and policy manager 136. 2 The call 
manager 135 of Comstock merely implements well known video conferencing functionalities 
such as call initiation (using the H245 control protocol), codec selection and the like. The 
call manager 135 does not deal with "objects". 

1 Kawai . column 4, lines 38-50. 

2 Comstock . column 8, line 66 through column 10, line 16. 
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Policy manager 136 operates to coordinate connection establishment and termination 
and may operate to control a video conferencing according to one or more policies. In 
general policies any rule, algorithm or combination or collection of rules and algorithms that 
may be applied to media streams in a video conference. This may include rules and 
algorithms that relate to assigning roles to media streams, as well as rules and algorithms that 
relate to handling media streams according to assigned roles. The policy manager 136 
implements a policy for displaying media stream bearing labels according to roles (people or 
content). The policy manager may permit a user to select, through a user interface 138, any 
number of people to display through a people display 154 and may allow the user to select 
specific participants for display. The policy manager may allow for establishment of a 
picture-in-picture display. The policy manager 136 may also require that only one content 
source may be selected at a certain time. The policy manager may further require that all 
participating terminals display content on their own local content displays. 

To manage the various policies, tokens are used to identify and control which terminal 
plays which role. Figure 3 of Comstock is a state diagram of token management by an 
arbitrating multipoint conference unit. In step 200, the system is initialized. At step 202 a 
token holder variable is set to NONE, indicating that no participant in the video conference 
currently holds the token. When a request 208 is received for the token, the process transmits 
an acknowledgement 210 of the request 208 and sets the token holder variable to the 
requesting terminal as shown in step 212. At some point, the process may receive a request 
224 for the token while the process is in a token held state 214. If request 224 is from the 
current token holder an acknowledgement is transmitted 210 and the token holder variable is 
again set to the requester 212. If the request 224 is not from the current token holder, the 
process continues to step 228 where a withdraw request is transmitted to the token holder. 3 

3 Comstock. column 10, line 17 through column 11, line 45. 
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Figure 4 of Comstock is a flowchart showing a process for initiating a video 
conference and uses roles according to the previously described concepts. After capabilities 
are exchanged and the logical channel is established, as shown in step 310, selected sources 
are coded and labeled. Source streams are coded using any suitable codex identified during 
the capability exchange. The streams are labeled according to the established or 
predetermined policy. A number of labels may be defined in an 8-bit label definition. The 
label may include designations of known media roles, for example 000: people; 001: content; 
010: mixed; 011: any; and 100-1 1 1 : reserved. These labels may be applied to media when 
the media is created. A media stream may be relabeled during use. 

However, the tokens of Comstock are only concerned with labeling displays of 
various media streams, and are not related to managing equipment via corresponding object- 
representations. However, assuming arguendo the classification of media streams into 
people or content types is creating objects, the media stream classification of Comstock is not 
"representing each type of video teleconferencing device as an object class" as recited in 
Claim 1 or "dividing the video teleconferencing devices into types of video teleconferencing 
devices" or "establishing an object class for each type of video teleconferencing device" as 
recited in independent Claims 15 and 27. That is, the streams of Comstock are not labeled 
differently if they are related to an MCU, (a first type of video device) endpoint (a second 
type of video device) or other videoconferencing apparatus (a third type of video device). In 
fact, such a labeling would be nonsensical on Comstock . 

B. Kawai and Comstock each fail to disclose a management bean as disclosed in 
Claims 2. 3. 4. 12. 13, 14, 16. 20. 23. 32 and 44. 

A Management Bean is a JAVA software construct (Specification, page 14, line 11- 

page 15, line 11; see also item 60 of Fig. 3B). Page 3 of the Official Action states that 

column 5, lines 1-20 of Comstock discloses Applicants' claimed management bean. 

Applicants traverse and note that this portion of Comstock merely describes that rack 10 may 
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include different hardware or software devices used in video teleconferences. A rack is, as 

shown in the corresponding figure, a cabinet and is not a Java Management Bean. Both a 

Real Networks compatible G2 encoder/streamer and a Windows Media codec are 

hardware/software interface devices, and are not inherently related to Java Management 

Beans. Similarly a generic directory server, conference scheduler, database server, 

authentication server, and a billing/metering system are not inherently related to Java 

Management Beans. A review of the entirety of Comstock (and Kawai) reveal no reference 

to Java Management Beans, or any other Java construct. 

C. Kawai and Comstock each fail to disclose or suggest an SNMP management 
instruction for a video teleconferencing device as recited in Claims 20 and 25. 

Kawai and Comstock each fail to disclose or suggest any sort of SNMP instructions, 
let alone providing a) an SNMP management instruction for a video teleconferencing device 
to an SNMP adapter; b) communicating the SNMP management instruction using the SNMP 
adapter as a management bean client in communication with the server; and c) 
communicating the SNMP management instruction from the server through the management 
bean representing the video teleconferencing device to the video teleconferencing device in a 
native protocol of the device as recited in Claim 20. Similarly, Kawai and Comstock each 
fail to disclose or suggest an adapter in communication with the application to accept SNMP 
instructions from the application for a video teleconferencing device; and an agent in 
communication with the adapter, the agent representing the video teleconferencing device as 
an object having attributes, wherein the adapter and agent cooperate to convert the SNMP 
instructions to the native protocol with the video teleconferencing device object attributes 
translated into requests to the video teleconferencing device in a native protocol of the video 
teleconferencing device during set-up or conduct of an active video teleconference, as recited 



19 



Application No. 10/039,932 

Reply to the Advisory Action of March 22, 2007 and the Official Action of January 30, 2006 

in Claim 25. Indeed, the Official Action provides no indication where these features may be 

found in the applied references. 

D. Kawai and Comstock each fail to disclose or suggest "a MIB having variables of a 
video teleconferencing device" or "an MIB summation engine operational to 
select one or more attributes and one or more variables to dynamically create a 
MIB" as recited in independent Claims 36 and 45. 

Kawai and Comstock each fail to disclose or suggest any sort of MIB or MIB 
summation engine, let alone one or more MIB having variables of a video teleconferencing 
network device; and a MIB summation engine operational to select one or more attributes and 
one or more variables to dynamically create a MIB for the video teleconferencing device 
during set-up or conduct of an active video teleconference as recited in Claim 36. Similarly 
Kawai and Comstock each fail to disclose or suggest dynamically creating a MIB for the 
video teleconferencing network device from selected attributes of the object associated with 
the video network device; and accessing the dynamically created MIB with the SNMP 
application to manage the video teleconferencing network device as recited in Claim 45. 

MPEP §706.02(j) notes that to establish a prima facie case of obviousness, three basic 
criteria must be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art reference (or references when 
combined) must teach or suggest all the claim limitations. Also, the teaching or suggestion to 
make the claimed combination and the reasonable expectation of success must both be found 
in the prior art and not based on Applicants' disclosure. In re Vaeck, 947 F.2d 488, 20 
USPQ2d 1438 (Fed. Cir.1991). Without addressing the first two prongs of the test of 
obviousness, Applicants submit that Claims 1-4, 6-10, 12-17, 19-23, 25 and 27-49 are not 
prima facie obvious because both Kawai and Comstock fail to disclose the above-discussed 
features of Applicants' independent and dependent claims. 
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Accordingly, in view of the present amendment and in light of the previous 
discussion, Applicants respectfully submit that the present application is in condition for 
allowance and respectfully request an early and favorable action to that effect. 

Respectfully submitted, 
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